昨天我們搞懂了單一登入 (SSO) 的底層邏輯，今天我們要正式踏入 Entra ID 讓人又愛又恨的深水區：將公會的應用程式接上雲端，並進行權限指派。
在帶大家動手實作之前，我們必須先釐清微軟架構裡最經典的「雙面人」機制，當你準備把一個應用程式（例如公會的打卡系統）掛上雲端時，你會在 Entra ID 後台看到兩個長得超像、極度容易讓新手搞混的選單：「應用程式註冊」與「企業應用程式」。

• 應用程式註冊
  這就像是應用程式的「設計圖」與「身分證」，IT 騎士團會在這裡定義這個 App 叫什麼名字、要使用什麼協定登入（像是昨天聊到的 SAML 或 OIDC），以及它需要向系統索取哪些 API 權限。
• 企業應用程式
  在技術上它被稱為「服務主體 (Service Principal)」，你可以把它想像成那張設計圖在你們公會（租用戶）裡的「實體化分身」，我們主要是來到這裡控管哪一位村民有權限看見並使用這個 App，同時也能在這裡掛上資安魔導團最愛的「條件式存取 (Conditional Access)」防禦結界！

實作

1. 註冊應用程式 (取得身分證)
   a. 使用全域管理員登入Microsoft Entra系統管理中心，進入應用程式註冊，並新增註冊。
   
   b. 填寫相關資訊

• 支援的帳戶類型
  • 僅單一租用戶：： 這是最封閉、最安全的選擇，這代表這個 API 應用程式只允許你們公會內部的人員或腳本來敲門。
  • 多個 Entra ID 租用戶：這是給 B2B 軟體商用的，允許全世界任何有微軟企業帳號的人。
  • 任何 Entra ID 租用戶 + 個人 Microsoft 帳戶：代表連路人甲用免費的 outlook.com 或 Xbox 帳號，都能嘗試發出請求。
• 重新導向 URI： 這次我們是做 API 串接測試，暫時可以留空，如果是真實 Web App，這裡要填寫應用程式接收 Token 的網址。
  

2. 配置 API 權限與管理員同意
   我們經常需要透過程式自動去撈取資安事件或使用者狀態，這時候就必須精準控制這個 App 能呼叫哪些 API，為了落實最小權限原則 (Principle of least privilege)，我們絕對不能隨便給予過大的權限。
   a. 進入API 權限，新增權限，選擇Microsoft Graph。
   
   b. 權限類型：應用程式權限，因為我們是自動化腳本，沒有使用者在螢幕前登入。
   選擇權限：SecurityEvents.Read.All，這樣App 只能讀取資安事件，不能亂動其他東西。
   
   c. 記得要點擊「代表 {你的租用戶名稱} 授與管理員同意」，看到綠色勾勾出現，權限才算真正生效，不然這時候拿著程式去呼叫 Graph API，會出現 403 Forbidden 錯誤。
   
3. 企業應用程式的指派與控管
   權限給好了，現在我們要換到「企業應用程式」的視角，決定誰可以使用它。
   a. 點擊企業應用程式，找到你的 App 分身：GraphAPI-Automation。
   
   b.指派測試帳號Cloud.User1
   
   
   c. 調整可見度：如果不想讓這個後台自動化的 App 出現在一般員工的我的應用程式版面上，可以把是否要向使用者顯示?調為否。